I would hold off on merging this too eagerly. For me this improves some benchmarks by quite a bit, but others also regress.

Mostly this tells me that overall CPU use seems to depend on the range set performance characteristics.

Another concern that bears some thought is the hazard of a CPU DoS attack. A peer can exert substantial control over the number of ranges in these fields, and the B tree structure is less sensitive to total size, though how much this matters depends on the exact accesses we're performing.

#2422 will also improve some B-tree operations, which might tilt the balance.

Another concern that bears some thought is the hazard of a CPU DoS attack. A peer can exert substantial control over the number of ranges in these fields, and the B tree structure is less sensitive to total size, though how much this matters depends on the exact accesses we're performing.

Could consider an enum that tries to make it an array range set, but switches over to a btree range set if the number of ranges grows beyond some small constant?

That should work, yeah, at the cost of a little more complexity and boilerplate.